1. Field of the Invention
The present invention relates to a method and system for guaranteeing a seamless session when replacing a push-to-talk-over-cellular (PoC) terminal in a PoC system, capable of replacing the PoC terminal without loss of a media stream for a running PoC group session when the PoC terminal is replaced for a specified purpose.
2. Description of the Related Art
Due to significant development of mobile communications technology and extension of mobile communications networks, various extra services and applications which make use of a cellular phone are being provided. At the same time, demand among cellular phone users for various extra services, such as a location service, a multimedia service, and a push-to-talk (PTT) service, is increasing. Among these extra services, the PTT service supports various supplementary functions such as an instant messenger function and a status display function, as well as a group call and a voice call which are also provided by an existing radio or a trunk radio system (TRS).
Currently, standardization of a push-to-talk-over-cellular (PoC) service which employs the PTT function in a mobile communication network is actively proceeding. One unique feature of the PoC service is that a user can participate in a plurality of PoC sessions, and can move among the PoC sessions to use a call service. Requirements that the user should move among the plurality of PoC sessions to use the call service are specified in the Open Mobile Alliance (OMA) which is a forum for specifying mobile communications services. The structure of an ordinary PoC service system will be explained below with reference to FIG. 1, which is a schematic diagram illustrating a conventional PoC service system. Referring to FIG. 1, a PoC client 10, as a service requester installed in a mobile station, is connected to a Session Initiation Protocol/Internet Protocol (SIP/IP) core network 30 which supports SIP and IP multimedia functions via an access network 20.
The PoC client 10 resides in a PoC user terminal to provide access to the PoC service. The PoC client 10 serves to establish a PoC session, participate in a PoC session that is currently proceeding, and terminate a PoC session. In addition, the PoC client 10 acts to make and transfer a talk burst, support an instant personal alert, and perform authentication when accessing the PoC service. Hereinafter, unless otherwise stated, both the PoC user and the PoC client 10 are assumed to be the same as a PoC service subscriber.
The SIP/IP core network 30 is connected to a PoC server 60, a GLMS (Group List and Management System) 50, and a presence server 70 in order to support the PoC service.
Generally, SIP is a standard defined in IETF (Internet Engineering Task Force) RFC (Request for Comments) 2543. SIP is an application-layer control protocol that is used to set up, modify and terminate a session or call for multimedia communication such as video and voice. SIP is a protocol that exists over an UDP (User Datagram Protocol)/TCP/IP layer, which supports both unicast and multicast sessions so as to be able to initiate the session by inviting participants to a multimedia conference with a client/server protocol capable of transceiving SIP Request and Response messages in a request/response fashion.
A SIP Request message provides six functions in RFC 2543 as follows: INVITE (Invitation to participate in a session), ACK (Permission to an INVITE request), BYE (Termination of a call), REGISTER (Registration with a redirect server by a user agent), CANCEL (Cancellation of a pending request), and OPTIONS. The SIP Response message provides status codes as follows: 1xx (Informational response), 2xx (Success response), 3xx (Redirection response), 4xx (Client Error, Request Failure), 5xx (Server Error), and 6xx (Global Failure).
The PoC server 60 serves as a Controlling PoC Function (CF) for maintaining and managing a PoC session, or a Participating PoC Function (PF) for participating in a PoC session for a one-to-one PoC call or a one-to-many PoC call (or group PoC call).
Functional blocks of the PoC server will be explained below with reference to the schematic diagram of FIG. 2.
The PoC server is classified into a Controlling PoC Function of taking charge of overall maintenance and management of a PoC session and a Participating PoC Function (PF) of taking charge of maintenance and management between each PoC session, which will be explained below with reference to relevant tables.
TABLE 1Controlling PoC Function (CF)Provides centralized PoC session handlingProvides centralized Media distributionProvides centralized Talk Burst Arbitration functionality includingtalker identificationProvides SIP session handling, such as SIP session origination,termination, etc.Provides policy enforcement for participation in group sessionsProvides participant informationCollects and provides centralized media quality informationProvides centralized charging reportsMay provide transcoding between different codecsSupports Talk Burst Control Protocol Negotiation
As shown in Table 1, the CF serves to maintain and manage a PoC session on the whole. The PoC server receives requests for a floor from PoC clients, arranges an order in which to give the clients the floor, and gives the clients the floor in that order. The PoC server also distributes a talk burst, for which an arbitrary PoC client makes a request, to all other PoC clients participating in a group PoC call, and provides information of the PoC clients participating in the group PoC call.
As shown in Table 2 below, the PF manages a PoC session between the CF and each PoC client. In particular, the PF acts to relay the floor between the PoC client and the CF when the PoC client makes a request for the floor or when the CF gives the floor to the PoC client. In addition, the PF serves to relay media between the CF and the PoC client, perform transcoding between different codecs, and filter one of two concurrent PoC sessions according to the choice of a PoC user when there is simultaneous talking in the two concurrent PoC sessions.
TABLE 2Participating PoC Function (PF)Provides PoC session handlingMay provide the Media relay function between PoC client and ControllingPoC serverMay provide user media adaptation proceduresMay provide the Talk Burst control message relay function between PoCclient and Controlling PoC serverProvides SIP session handling, such as SIP session origination,termination, etc, on behalf of the represented PoC clientProvides policy enforcement for incoming PoC session (e.g. accesscontrol, incoming PoC session barring, availability status, etc.)May collect and provide media quality informationProvides the participant charging reportsMay provide filtering of the media streams in the case of simultaneoussessionsMay provide transcoding between different codecsMay support Talk Burst Control Protocol NegotiationStores the current Answer Mode and Incoming PoC Session Barringpreferences of the PoC client
In the PoC service system as described above, the PoC user can input information on a group and its members to the GLMS 50 through his/her PoC terminal, and can be aware of information about PoC users who he or she can call through an individual or group list transmitted from the GLMS 50. Alternatively, the information on the group and its members may be input, corrected and managed in the GLMS 50 via a reliable communication network such as the Internet or Intranet which a PoC service provider can trust.
In order to make use of the PoC service, the PoC user registers his/her PoC address with the SIP/IP core network 30. The SIP/IP core network 30 stores PoC user information at the request of the PoC user. Thus, when another PoC user tries to request a group PoC call, the PoC user registers his/her information in the SIP/IP core network 30 in advance as described above, and requests the group PoC call to his/her SIP/IP core network 30 by using group identification information transmitted from the GLMS 50. At this time, the SIP/IP core network 30 performs address determination and domain location determination by using information of the call requesting PoC user and then transfers a PoC call request to a home PoC server 60 with which the call requesting PoC user is registered. In regard to the PoC call request, the PoC 60 server prepares for establishment of a PoC session, obtains each user's information from the GLMS 50, and then transfers a PoC call request signal to a corresponding SIP/IP core network 30. Here, in the case of a PoC call request to users within an Intradomain, the PoC server 60 performs both the CF and PF. The PoC server 60, which manages a call-requested PoC user, requests a PoC call to the PoC user after the SIP/IP core network 30 performs the location determination procedure, by using information of the PoC user that is transmitted to the PoC server 60.
FIG. 3 is a schematic diagram illustrating CF and PF blocks of a PoC server.
Referring to FIG. 3, PoC clients 111, 121, 131 and 141 provide access to a CF 100 through PFs 110, 120, 130 and 140 respectively, thereby establishing a PoC session. Here, when a floor is granted to a requester qualified as a talker from the CF 100, media based on speaking of the corresponding PoC client is transmitted to each PoC client.
First, in order to describe in full detail a session connecting procedure, etc. of a PoC client in a terminal, the following features of the PoC system defined in the OMA will be discussed. The PoC system according to setup of the originating and terminating sides of the PoC session in the OMA has the following features.
The PoC system is divided into two types, an on-demand session mode and a pre-established (or early) session mode, according to how the connection with a PoC server 60 in the home network of a user is set up.
The pre-established session mode means that the PoC user sets up a specified session between the PoC client and the PoC server 60 within his/her home network in advance by his/her request. The pre-established session is necessary to enable the PoC user to negotiate media parameters to be used with the PoC server 60 in advance, and thus perform rapid call setup without negotiating again the media parameters to be used in the future between the server and the client. In order to establish the early session, the PoC client provides media parameters supported to a SDP (Session Description Protocol) body through an SIP INVITE method, and responds to media parameters provided from the server. The PoC client returns identification information of the early session which is newly set up for a response message to the PoC user including a conference URI (Uniform Resource Identifier). In the case of using the early session, it is possible to set up an IP address, a port number, a codec to be used, a talk burst control protocol, etc., in advance.
The on-demand session mode refers to a state where the PoC user does not set up the early session, and means that the PoC user performs a PoC call connecting procedure after receiving an INVITE message of another PoC user.
Meanwhile, the PoC system makes a half-duplex group PoC call possible, including the above features. This multilateral conferencing function is an exemplary feature of the PoC system, and may be divided into an ad hoc PoC group, a pre-arranged PoC group, and a chat PoC group according to the feature of a group that is set up.
In the PoC system having the foregoing features, the respective elements such as the PoC client, PoC server, SIP/IP core network, group list server, presence server, and so on, as well as procedures of initiating and connecting an initial PoC session through signaling between these elements can be found from the OMA standard draft as the conventional SIP-based technology, and so their description will be omitted.
Meanwhile, in the conventional PoC system having the foregoing features, there may occur situations where a PoC client participating in a currently proceeding PoC session should be replaced.
As concrete examples of this situation, in a first situation, a currently participating PoC session has a feature of supporting not only a voice, but there is a need to replace media, such as a video, including the voice as a call is made. In this case, some PoC users using a voice support terminal have to replace their own PoC client with video support terminal.
In a second situation, power of a currently used terminal is almost consumed, but there is a need to continuously participate in a current PoC session without termination.
In a third situation, a user is participating in a PoC session using a stationary PoC terminal (e.g. a VoIP terminal) at his/her office, but feels a need to move. In this case, there is a need to connect a currently participating session using his/her mobile wireless terminal (mobile PoC terminal).
In addition to these examples, a need to replace the PoC terminal by a special request of the user may frequently occur.
With respect to this requirement, a conventional process of replacing a PoC session on the basis of OMA PoC 1 standard technology will be described with reference to the flow diagram of FIG. 4.
FIG. 4 shows a process where a PoC client A1 111, as a terminal that has already participated in a running session, attempts to participate in a running session using a PoC client A2 112 by request of a user.
First, a PoC client A1 111 transmits an SIP BYE message to a PF A 110 of his/her home network in order to terminate a participating PoC session (S101), and thus the PF A 110 transmits the BYE message to a CF 100 through information on an SIP address contained in the BYE message (S102).
Next, after receiving the session BYE message, the CF 100 transmits a 200 OK response signal for terminating a PoC conference (S111 and S112), thereby releasing the PoC client A1 111 and stopping transmitting media at the same time.
Meanwhile, a PoC user who terminates the session transmits an INVITE message to the PF A 110 via the PoC client A2 112 in order to participate again in the previous session using a new PoC client (S121). The INVITE message is transmitted through the PF A 110 to the CF 100 having control over the running conference session (S122). At this time, the PoC client A2 112 must have unique identity information of the PoC session (session ID) in order to participate the proceeding PoC session again.
Next, the CF 100 transmits a 200 OK response (S131 and S132), thereby allowing the new PoC client A2 112 to participate in the session, receives an ACK signal (S141 and S142), and confirms the participation of the session. Simultaneously, the CF 100 transmits a corresponding floor message to the PoC client A2 112 according to a floor in the current session. When another PoC client transfers media, the CF 100 transmits a Floor Taken message to the PoC client A2 112 using RTCP (Real-time Transport Control Protocol) (S151 and S152).
Thereafter, when the session is connected, the CF 100 transmits media to the PoC client A2 112 using an RTP (Real-time Transport Protocol).
The foregoing conventional process has the following problems.
First, when the PoC user participates again in the same PoC conference session in which he/she participates as the PoC client A1 using the PoC client A2, he/she must have the PoC session identity. However, the PoC session identity, that is generated arbitrarily as in an ad hoc session, should be transmitted to the PoC client A2 by manual input of the user.
Further, the PoC client A2 cannot make use of SIP session dialog information which the previous PoC client A1 is putting to use. As such, the PoC client A2 fails to receive a media stream using a session dialog that has been already used.
Therefore, there is a possibility that the QoE (Quality of Experience) of the user will deteriorate because the PoC client A2 fails to receive the media stream of the PoC session while replacing the terminal of the PoC client.